REMARKS 



Claims 1-22 are currently pending in the Application. In an office action 
dated September 25, 2003 ("Office Action^ th* p • 

uscsm , n , . * ACtl ° n 1 * e Examiner re J e ^ed claims 1-22 under 35 

U.S.C § 103(a) as being unpatentable over Liu et al., U.S. Patent No. 6,009 541 ("Liu") 
* V.W of ShanW et al., U.S. Patent No. 6 ,3 81 , 656 (',hanW,. A pp ^, 
representee respectfully traverses these 35 U.S.C. § 103(a) rejections 

Consider claim 1, provided below for the Examiner's convenience: 
testing platform comprising * C ° mpUtin « resour <* environment, the 

V'occssingof^^^^^ receives *P« commands and initiates 

a test routine; and 

computing resoZeZZntT^l^^' and software interfaces of the 

shield the test execution engZeand Lt ZiZ fZZ r ° Utine and '<*<* 

software interfaces of the computinT f de P^encies on the hardware and 
system interface, (emphasis added) ^nment, including the 

operating 

Please note that the claimed testing platfonn includes components that shield the test 

i~ : 8 :: md tes ; routme from de ~ - - — an d so *z 

m erfeces of the computing resource environment, including the operating system 
interface. Again, for the Examiner's convenience the fen ■ 

o ! , wiivemence, the following paragraph from the current 

application, begmnmg on line 22 of page 5, with reference to Figure 2 of the 1 T 

is provided to further understanding of claim 1: ^ aPPhCati ° n ' 

includes a coJ^J^S^^^^ test execution engine212 that 
test routines according to v^w Zl™ , y executes ln to run one or more 
routine 210 and the tef t execution ^S^J^^ P™*** Both ^ test 
components from dependencies on X com„Z? * addltlonal testi ng Platform 

204-205, 206-207, and 208 wik^ ^ZZ^^t ^ CXtemaI ^^202, 
The test execution engine 212 imelfacesToTSTrl ? ^ t£Sting P Iatfol ™ ™s 

via a result handler cLfKmJ?£?^^^ data stora 8 e devices 204-205 
system-provided functionality 202 'via JZ ,! engme interfaces to operating- 

Figure 2 as a generated operating rvTS^^ 1 ^ t0gether * 
interfaces to user I/O devices 206-207 TzTu^vnl ^ teSt CXeCUtion en S™ 

engine interacts with the test rZ^l 2 ™ T*™™ 218 ' ^ execution 
component 222, and a test execlr component 224 £ ^ a Se£ J Uencer 

the result handler component via a SJSSSi * 2 nita,c 210 interfaces with 
operating system adaptor, userl/O handS ™H C ° mp ° nent 226 311(3 interfaces with the 

U Handler, and a communications interface 228 via a 



In both the emoted ,ex t , and in Figure 2 , it is ^ ^ 

platform » a self-contained, logically group of componenls ^ ^ ^ 

front, ,he operating system „f the conmuting resource jn ^ ^ 

Platform runs. Applicant de.ibera.ely designed the claimed testing platform i„ ^ way 
for, among others, portability reasons, as de,ai.ed in the below quoted portion of the 
paragraph beginning on line 21 of page 8 of the current application: 

compel "of L" 1 ^rltfoZ'^n 1 ^ ° f f. hiel . din8 Provided «" 

adaptability, and porU^offfiE ti tnl o^on^f ,'T' S ° f 

test various hardware and wfWe c»™3 , ST ° f rou,,nes Sloped to 

be ported to almosTaS VwZL " P,Sttorm ' f ° r 

operating systems 'J^K! SZTT^StS^T ""^I 

Next, please again consider the cited references. Liu's extended BIOS 
testing diagnostic routine "is a separate block of code stored within a common ROM with 
the BIOS test routine. In another embodiment, the extended diagnostic routine is stored 
» a hard disk drive" (column 3, lines 9-13). In one embodiment, "the diagnostic routine 
begtns by reading to and writing from the central processing unit (CPU). The routine 
may check severa, standard CPU registers which record errors ...» (commn 3, line 67 - 
column 4, line 3). In one embodiment, "the diagnostic routine a!so performs a test of the 
Penpheral Component Interconnect (PCI) cards and buses or other type of bus 
components (column 4, lines 6-8). Therefore, as also noted by the Examiner, Liu most 
explicitly and decidedly does no, include "components tha, serve to adapt hardware and 
software interfaces of the computing resource environment to the tes, execution engine 
and test routine and tha, shield the test execution engine and tes, routine from 
dependencies on the hardware and software interfaces of the computing resource 
envtronment, including the operating system interface," as clearly claimed in claim 1 
Lm teaches exactly an opposite strategy, with Liu's diagnostic routine - an simple' 
unshtelded code block - directly accessing hardware components such as CPU registers' 
PCI cards, and buses, In Apphcant's representative's viewpoint, Liu is completely' 



unrelated to the claimed invention. Indeed, Applicants testing platform can be furnished 
with a test routine that test particular hardware components, but Applicant's test routine 
interfaces to layers of tiered, hierarchical shielding components, rather than directly to 
CPU registers, buses, and other computer resources within the computer-resource 
environment in which Applicant's testing platform happens to be running. 

Shankman appears to be equally unrelated to the current, claimed 
invention. Shankman provides a method and system for monitoring performance of I/I 
processors included within server hardware by introducing a virtual monitor diagrammed 
in Figure 4 into each I/O processor, and including an I/O monitor, diagrammed in Figure 
5, within the server to collect I/O messages from the virtual monitors, and reporting 
performance data to an I/O user interface (Abstract of Shankman, Figure 4, and Figure 5). 
As stated in the Summary, Shankman's virtual-monitor-and-I/O-monitor system 
"monitors message traffic passing through the input/output ("I/O") processors within 
servers in a computing system in order to analyze the I/O processing within the 
computing system as a whole" (column 3, lines 1-5). Shankman's virtual-monitor-and- 
I/O-monitor system is not a testing platform. The concept of testing is well known in 
computer science, as stated in the current application beginning on line 1 9 of page 1 : "A 
sizable body of theory and technology related to testing and quality assurance has 
evolved along with the evolution of computers and software technologies." Testing 
involves exhaustive exercise of, or at least well-planned sampling of, the state spaces 
involved in running software programs and hardware devices. For example, a software 
routine is commonly tested by invoking the routine with as many different parameter 
values and input data as possible, to insure that each instruction within the routine 
executes properly for the range of input values that may be encountered. By contrast, 
performance monitoring is a different area of computing. In performance monitoring, 
statistics and data related to operation of a routine, device, or system are collected and 
analyzed to ascertain how the routine, device, or system operates. Performance 
monitoring may well be employed in testing, but is not itself testing. For example, a test 
routine could iteratively alter various system states and then monitor the resulting 
performance. But testing involves, in such cases, experimentation - developing a 
hypothesis, perturbing a system, observing the effects of the perturbation, refining the 



hypothesis, and continuing iteratively until a hypothesis is validated by observation. 
Performance monitoring may comprise the observational step in an experimental 
procedure, but is, by itself, neither a test nor an experiment. 

Shankman, for example, neither discloses nor suggests a test routine, or, in 
other words, a routine that implements an experimental test procedure, since performance 
monitoring involves merely passively collecting performance data. Applicants test 
platform "includes a core test execution engine 212 that includes a central execution loop 
that continuously executes in order to run one or more test routines according to various 
user-input and programmed parameters." Shankman, for this reason alone, neither 
teaches nor suggests the testing platform of claim 1. 

Not only is Shankman f s system not a testing platform, Shankman's virtual- 
monitor-and-I/O-monitor system is also not shielded from dependencies on the hardware 
and software interfaces of the computing resource environment, including the operating 
system interface. Consider, for example, Figure 5 of Shankman and the accompanying 
text beginning at line 3 of column 8: 

FIG. 5 is a block diagram depicting the I/O monitor 201 shown in FIG. 2 and its 
interfaces to other elements of the monitoring system, according to an embodiment of the 
invention. The I/O monitor interfaces with the I/O user interface 220 running on the 
workstation 200, the virtual adapters 204-206 and with server devices 501 on the server 
101. The I/O monitor 201 interfaces with the server devices 501, including both I 2 0 
devices 502 and non-I 2 0 devices 503. 

As shown in Figure 5, and explicitly stated in the above text, Shankman's I/O-monitor 
directly interacts with hardware devices. Moreover, Shankman's virtual monitor directly 
interacts with the operating system of the I/O processor in which it runs, as clearly shown 

i 

by the double arrow interconnecting the communications module of the virtual monitor 
402 and the I/O processor operating system 430 in Figure 4. There is no shielding of 
Shankman's virtual-monitor-and-I/O-monitor system from hardware dependencies - 
instead, components of Shankman's virtual-monitor-and-I/O-monitor system are directly 
embedded into the computer system components and directly interface with them. 

The Examiner points to column 1, lines 6-10 of Shankman to show that 
Shankman provides a testing platform, but, in Applicant's representative's opinion, the 
Examiner has misstated what those lines of Shankman clearly state. The cited passage 



reads, as follows: "The invention relates to a computer input/output ("I/O") subsystem 
monitor for testing, debugging and performance analysis and, more particularly, to I/O 
subsystem monitoring in computing systems using an intelligent I/O ("I2O") 
architecture." (emphasis added) Certainly performance monitoring may be related to 
testing, as discussed above, but it is not testing, and Shankman does not disclose a testing 
platform. The Examiner states that, in column 4, lines 15-13, Shankman discloses 
adapters that conform to an intelligent I/I architecture that adapts the monitoring 
execution system to the operating system, but Shankman does not disclose anything of 
the kind in these cited lines. Instead, Shankman describes why he describes the 
components of his system that execute on I/O processors as "virtual adapters." 
Shankman states: "A virtual adapter inserts itself into the message stream of an I/O 
processor ("IOP") and may then monitor 120 messages passing through the IOP. An 
'adapter 1 in 120 parlance comprises any hardware entity compliant with the 120 
architecture." The term "operating system" does not appear in the cited lines. 

In summary, Liu's BIOS diagnostic testing routine is a standard testing 
routine that intimately and directly interacts with the hardware components of a computer 
system. Shankman discloses a performance monitoring system that also intimately 
interacts with both hardware components and operating systems. Neither reference 
discloses, teaches, or suggests "a test execution engine that receives input commands and 
initiates processing of the input commands" and neither reference discloses, teaches, or suggests 
"components that serve to adapt hardware and software interfaces of the computing resource 
environment to the test execution engine and test routine and that shield the test execution engine 
and test routine from dependencies on the hardware and software interfaces of the computing 
resource environment, including the operating system interface." Liu does disclose a testing 
routine. Shankman fails even to disclose a testing routine, and therefore is unrelated to any of the 
three elements of claim 1 . 

Applicant's representative would like to emphasize that the disclosed and 
claimed testing platform and test routines represent a significant departure from 
commonly employed testing applications and systems. Applicant's testing platform is 
truly portable, because, being shielded from any particular computer resource 
environment. Applicant's test routines are also shielded from any particular computer 
resource environment. Applicant's representative worked for 13 years in the computer 



industry, and has been involved for more than 8 years in patent prosecution of computer- 
related inventions, and has not professionally encountered a similar testing architecture. 

All of the claims remaining in the application are now clearly allowable. 
Favorable consideration and a Notice of Allowance are earnestly solicited. 

Respectfully submitted, 
John S. Eden 
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